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Abstract 

The objective of the real -: -econfiguration study was to implement a physical test bed for testing and 
evaluating a suite of reconfi: ἢ algorithms. The software architecture was composed of an operating 
system which supported rea: ...:i¢ programming concepts, a set of model tasks, control software, and the 


suite of reconfiguration procedures. Rate Monotonic scheduling was used to schedule the execution of the 
task set, as well as for testing the schedulabilit, of new configurations. Of primary concern was the execu- 
tion time of the reconfiguration algorithms. The general problem of reconfiguration is similar to the bin 
packing problem and is NP-Complete. This suite implements a concept of “disturbance”, a cost associated 
with moving a task from one CPU to another, to reduce execution time. The hardware platform was com- 
posed of a VME chassis populated with § Motorola 68030 CPUs. 
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Summary 


This report documents the implementation and evaluation of the reconfiguration algorithms developed 
for IBM bv Dr. John Lehoczky and Lui Sha of Logic Associates. The algorithms were implemented on a 
standalone system for testing and debugging. Then the algorithms, along with a model task set and control 
software, were transported and integrated on a test bed composed of a VME chassis and 5 Motorola 68030 
CPUs. The net result verified that the test bed performed as predicted by the algorithms as long as the set 
of tasks were independent. 
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introduction 


This report documents the effort to implement a set of reconfiguration algorithms developed for IBM 
by Dr. John Lehoczky and Lui Sha and evaluate their performance. The reconfiguration problem is the prob- 
lem of finding a way to place a set of modes (a mode is a set of processes) into a set of CPUs without exceed- 
ing CPU, memory, or other system constraints such that all hard—deadline response requirements are met. 
Usually a reconfiguration problem will start with a working system (mode to CPU mapping), and a CPU 
is removed or disabled, causing a need to redistribute the modes among the remaining CPUs. This type of 
reconfiguration has potential use in systems where it is critical that processing continue in the presence of 
failed or disabled CPU resources in such a way that critical system response requirements are satisfied.. 


In Phase I of the study IBM established the process model for a sample system problem. This included 
a definition of how many concurrent system modes would be active, how many processes comprised each 
mode, whether processes could be co-resident with certain other processes, what the functional criticality 
of the modes were, etc. Also, included in Phase I was the design of a test bed. During Phase II, IBM was 
to implement the algorithms on a physical network/processor test bed, to evaluate performance of a live 
system, relative to the theoretical performance predicted by the algorithms. 


The algorithm set consists of five algorithms: RECONF, RFFD, MFFD, CLUSTER, and SCHED. RE- 
COMF is the controller. It initializes the system, accepts user inputs, and calls the other algorithms as need- 
ed. RFFD stands for Reverse First Fit Decreasing, and is responsible for computing which modes may be 
moved during a reconfiguration attempt. MFFD stands for Modified First Fit Decreasing. This algorithm 
places movable modes into CPUs according to their characteristics and resources. CLUSTER is used if the 
results of MFFD do not satisfy interprocess communications constraints. SCHED, used when processes are 
being placed into CPUs, is used to determine if the set of processes assigned to a CPU will all meet their 
deadlines under the Rate Monotonic Scheduling paradigm. Other constraints consist of CPU utilization, 
memory utilization, pseudo resources, communications channel bandwidth and disturbance limitations. 


In the mode/process model used on the test bed, “odes are composed of one or more processes, and the 
processes may pass data among themselves (via TCP/IP sockets). Rate Monotonic Scheduling, however, 
requires that the set of processes be independent (meaning no process can effect the execution of another 
process except by higher priority preemption) before it can guarantee that all the processes will meet their 
deadlines. If the sccket calls are made non-blocking so that the processes are independent, issues regarding 
data integrity and synchronization are raised. For this report no interprocess communication requirements 
were defined in any of the test cases. 


Since the problem ot reconfiguration is NP—Complete (similar to bin packing), exhaustive exploration 
of all possible combinations becomes computationally prohibitive at some point, especially if encountered 
in areal—time environment. The algorithms developed do not attempt to test all possible combinations, but 
rather try to satisfy a set of criteria. The criteria used by these algorithms is based on a concept of distur- 
bance”. Each mode is assigned a disturbance value by the designers of the system which approximates the 
cost of suspending a mode, moving it to another CPU and reactivating it. The concept is extended slightly 
to handle non-linear cases, such as when the cost of moving a pair of modes is more than the sum of the 
costs of the individuals. The algorithms go one step further, and also try to minimize future disturbance. 
Future disturbance is the theoretical cost of reconfiguring a system again, due to another failure. Since not 
all possible combinations are checked, the algorithms may fail to generate any configuration, even though 
a valid configuration exists, or they may not compute the best configuration possible. But the approach tak- 
en by the algorithms attempt to do the best job possible considering the constraints. 
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Overview 


Hardware/Software Environment 


The real-time reconfiguration study was supported by a number of platforms and environments during 
its development. The target development and test platform consisted of the following components: 


@ SUN 3/470, with 32 Mb memory. Sun OS 4.0.3. 


@ Five Motorola MVME-1475A~1 or MVME--1475A-—2 CPU boards mounted ina 
VME chassis. 


Five VME transfer cards supporting Ethernet interfaces. 
Ethernet to connect Sun development/Test platform with CPU boards. 


The five CPU boards and transfer cards were installed in a single VME chassis. Figure 1 on page 3 show 
how the boards were arranged. Note that the speed of the CPUs on the 1475A-1 and 14754--2 are not the 
same, but this was accounted for in the tests. The reconfiguration algorithms require a set of identical CPUs. 


For the operating system on the CPU boards, pSOS ™ from Integrated Systems, Inc. was used. It supports 
priority tasking with preemption, remote debug, and TCP/IP sockets. One of the major design goals was 
to restrict interprocess communication to TCP/IP sockets, and avoid communications via the VME back 
plane. So, although the initial test bed consisted of a single VME chassis, the VME back plane was not 
utilized for interprocess communication purposes. 


Ethernet 
Figure | MVME-147 CPU/Transfer board arrangement in VME chassis 


Process Model 


Under the pSOS operating system there is a °C’ function designated as the “root” which is initialized to 
run when a program is down loaded to a CPU board. This task is also initialized to run at the highest priority 
available. In the implementation of the reconfiguration algorithms, the root task is used as a task controller 
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for the other processes assigned to that particular CPU. One CPU is designated the master which also has 
the responsibility for polling the other CPUs for detecting CPU failure, and computing and transferring re- 
configuration data. The other CPUs are thus considered slaves. One of the responsibilities for the root pro- 
cess in each CPU is to initiate the complete set of processes. Each process then determines if it should be 
executing or not based on which CPU it isin. In this implementation a single flexible process model is used 
to simulate process execution. The code for each process is identical, but execution is controlled by a table 
of parameters. This method allows a process to initiate data transfers, receive data transfers or both or nei- 
ther, to/from any other process in the system. By consulting the globa! configuration data, each process can 
determine if the process with which it is to interact is located on the same CPU or not and to act appropriately. 
The following design segment is for the root controlling task. 


/* Design for the Root control process */ 

Root (MyCPU) 

Begin 
Initialize ‘race tables, local variables, the network interface 
Read initial CPU configuration data 
Create set of generic processes 


Open sockets to root processes in other CPUs 


Loop forever 
If this root process is in the master CPU 
Then 
Send ‘query’ messages to other CPUs 
Receive responses from other CPUs 
If new CPU failure detected 
Then 
Suspend all generic processes 
Send ‘starting reconfiguration’ message to other CPUs 
Execute reconfiguration algorithms 
Send new configuration data to other CPUs 
Restart and resume generic processes 
End if 
Sleep 10 seconds 


Else /* This is a root process in a slave CPU */ 


Wait for message from root master CPU 


If 

‘query’ message received 
Then 

Send ‘Query response’ 
Else 
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/* ‘starting reconfiguration’ message received */ 

Suspend all generic processes 

Receive new configuration data 

Restart and resume generic processes 

End if 
End if 
End loop forever 
End Root 


Figure 2 Root Process Design 


The following design segment is for the generic process model. The calculation of the deadline is com- 
puted as process period plus the previous deadline. This method of computing a deadline maintains an envi- 
ronment where Rate Monotonic Scheduling can be used. At the bottom of the cycle of the model process, 
the current time is queried. When current time is before the computed deadline time, the task is suspended 
until the deadline to maintain its period. If the process has run beyond its deadline, a deadline error is re- 
corded, and the task is not suspended to minimize the delay until the start of the next cycle. This is one simple 
method that maintains a Rate Monotonic Scheduling Structure. The pSOS operating system supports tasks 
with priorities and task preemption. 


/* Standard multi-purpose Client/Server task model */ 

Generic_Process (Procid) 

Begin 
Initialize counters, trace data, and other local variables. 
Block here if this process is not assigned to this CPU. 
Compute initial deadline 


Loop forever 
If CPU configuration has changed 
Then 
Close open sockets 
If input is from a remote CPU 
Then 
Open socket to remote CPU 
End if 
If output is to a remote CPU 
Then 
Open socket to remote CPU 
End if 
End if 


If input is from a remote CPU 
Then 

Read data from socket 
End if 


Perform CPU intensive processing, to simulate expected CPU usage. 


If output is to a remote CPU 
Then 

Write data to socket 
End if 


Unclassified 


Real-Time Reconfiguration Study (Final Report) 


Compare deadline time to current time 
If deadl:ne passed 
Then 
Record deadline passed Error 
End If 


Compute new deadline time 
If new deadline time has not been passed 
Then 
Sleep until deadline time 
End If 


Block here if this process is not assigned to this CPU 


End Loop forever 
End Generic_process 


Figure 3 Model Process Design 


Program Notes 


The above designs are only one of many possible designs. Several factors are assumed or over looked 
in favor of simplifying the implementation. Some, but not all of the factors include: 


No accounting for process state data. When a process is moved from one CPU to 
another, it will lose its state data unless some extra action is taken. 


Reconfiguration stops and restarts all generic processes, even those unaffected by 
the reconfiguration. Ideally, only those processes actually relocated should be 
effected. 


At most one possible input and one possible output per process cycle. The pa- 
rameters which control input/output allow for skipping cycles to allow processes 
with different periods to transfer data (as long as one period is a multiple of the 
other). Note no input/output requirements were defined to allow the process set 
to remain independent. 


No CPU time is used to move or copy data into/out of a process when its input/ 
output is to a process in the same CPU. 


Each process uses it rated percent CPU each cycle. The CPU used by a process is 
really the sum of the ’cPpU intensive processing’ phase plus the time spent 
getting or sending input or output data. Since the same number is used to control 
the length of the ’cpu intensive processing’ phase as which defined the 
CPU usage of the process, the time spent getting or sending input or output data is 
not accounted for. 


For testing, a data file containing the initial configuration is the source of input for the reconfiguration 
program. Compiler flags allow the development of slightly different versions of the program. One version 
allows the name of the input data file to be a command line parameter. Another, planned for use on the test 
bed, gets its input data from a ’C’ code program fragment. This is required because file I/O is not supported 
in our test bed implementation. The compiler flags also allow for various levels of debug capability by in- 
Cluding or excluding ’printf()’ statements. The test bed implementation is not expected to support "printf()’ 
capability, so those functions are also excluded in the test bed version. To monitor the execution of the pro- 
cesses down loaded to the CPU modules, the pSOS interactive debugger is used. Every attempt was made 
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to minimize overhead associated with the monitoring of the execution of the processes. such as storing wace 
data in memory while the tests were executing and reviewing them afterwards. 


The root process, and a system network process have the highest priority on the test bed. It is unknown 
what the exact nature of the network process is other than it processes incoming and outgoing network pack- 
ets. Its operation is considered overhead. The root process also has a priority higher than any of the genenc 
processes. The root process, however, is not following the RMS rule where its priority and period should 
be inversely proportional. Currently it polls the other CPUs once every 10 seconds. During normal opera- 
tion of a test, its processing is also considered overhead. During reconfiguration, which may consume a 
substantial amount of CPU, the reconfiguration algorithms run at the root level of priority. But, since all 
processes are suspended, this is not a concern. If, however, the processing of the reconfiguration data is 
improved to the point where only processes affected by a change are disrupted, this design will have to be 
changed to accommodate this processing. Reconfiguration processing is acyclic by nature, but, in order to 
not disrupt the currently executing processes in the same CPU, it should be run at a very low priority. 


Probably the biggest departure from real world systems is the problem caused by real world sets of pro- 
cesses not being truly independent. As an initial step it was appropiate to assume independence as this will 
provide a baseline against which future, more complex studies may be measured. Even when the process 
set is made independent by using non~blocking reads/writes, new questions concerning data integrity and 
synchronization occur. Typically system designers "hardcode” a time line in their systems so they can verify 
data flows at the appropriate times and rates. These systems rarely account for changes in CPU resources 
or even have the ability to relocate processes. Investigation into the problems and solutions of data integrity 
and synchronization with independent processes was beyond the scope of this study. 
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Results and Discussion 


Descriptions and Test Cases 1-3 


The following figure explains the notation used to represent CPUs, modes, and processes. 


Percent CPU 
Cie std ibibo 
Qh χ SOL 2 


Total 


Percent CPU 
\rotal 


Percent 
Memory 


Percent Memory 


Process 
Period 


Figure 4 Description of a mode description block. 


A system is composed of a set of CPUs and a set of modes. A mode is comprised of a set of related pro- 
cesses (one or more). The processes are depicted on the left side of the mode description block. Each 
compartment represents a separate process and includes data on the processe’s CPU usage, memory require- 
ments, period of execution and a unique id. The middle portion shows total CPU/memory utilization, and 
the disturbance factor associated with the mode. The right edge shows the mode id. The algorithm set sup- 
ports pair-wise and triple—wise disturbance factors among modes but no such factors were defined for tests 
in this report. 


The first example (figure 5 on page 9) shows the standard test case consisting of 5 CPUs, 8 modes and 
19 processes. The fifth CPU is empty and considered a spare. For cases where only one of the other CPUs 
(except CPU 0) fail, the modes and processes of the failed CPU are merely relocated to the spare. In the 
test bed system CPU 0 is used to detect failures in the other CPUs and control reconfiguration and is not 
allowed to fail. The ratio at the bottom of each CPU is the total CPU/total memory utilization for that CPU. 


The first set of reconfiguration examples are generated from the standard test case by failing CPU 1 and 
CPU 4 (the spare), then CPU 2 and the spare, and then CPU 3 and the spare. Each of these cases forces the 
processes in the failed CPUs to be distributed to other still functioning CPUs. The reconfiguration algo- 
rithms are run and they attempt to minimize total system disturbance, but also respect CPU resources and 
the Rate Monotonic schedulability of the resulting task sets. 
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CPU 4 


ἘΠ 4] 


0/0 (Spare) 


Figure 5. Standard initial system configuration for test cases 1-3. 


Test case 1, CPUs 3 and 4 are marked as failed, and the resulting configuration is shown in figure 6 on 
page 9. 


CPU 0 


0/0 (Spare) 


86/55 


Figure 6 Reconfiguration Case 1: After 


Test case 2, CPUs 2 and 4 are marked as failed, and the resulting configuration is shown in figure 7 on 
page 10. In this case the two processes of mode 5 are split apart and placed in different CPUs. 
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CPU 3 


58/75 


Figure 7 Reconfiguration Case 2: After 


Test case 3, CPUs 1 and 4 are marked as failed, and the resulting configuration is shown in figure 8 on 
page 10. 


Figure 8 Reconfiguration Case 3: After 


In addition to the mode/process definitions, each set of processes may have a communication graph de- 
picting the source and destination of data flows. For the set of modes/processes depicted in figure 5, a sample 
communication graph is shown in figure 9 on page 11. In a complete communication graph, the directed 
arcs would be augmented with bandwidth data. Communication graphs are not required, but if a graph is 
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defir-ed for a reconfiguration problem, it is checked against communication channel bandwidth limitations. 
Wien bandwidth limitations are exceeded, the clustering algorithm is used to check for another configura- 
tion which may exceed disturbance limitations, but not exceed channel bandwidth limits. 


CPU 0 CPU | CPL 2 CPL 3 


OO 


Figure 9 Sample Communication Graph 


Test Case 4 


The fourth test case demonstrates the case where greater than zero additional disturbance is required, and 
a mode from a non-failed CPU must be relocated. The before configuration is shown in figure 10 on page 
12. The initial configuration is very similar to the initial configuration of the test cases above, only the per- 
cent CPU of process 0 is changed (from 28% to 33%). 
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CPU 4 


Ei 


0/0 (Spare) 


Figure 10 Test Case 4: Before 


CPU 2 is marked as failed, and modes 4 and 5 must be relocated. This system cannot be reconfigured 
without incurring the additional disturbance cost of relocating a mode from a non-failed CPU. Mode 2 
which started out in CPU 1 was moved to CPU3. Mode 4 from failed CPU 2 was moved to CPU 1, and mode 
5 was split across CPUs 0 and 1. The results are shown in figure 11 on page 13. 
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CPU 4 


0/0 (Spare) 


Figure 11 Test Case 4: After 


Rate Monotonic Scheduling 


Rate Monotonic Scheduling is a scheduling algorithm. When a set of tasks are being scheduled according 
to its rules, it is possible to determine the schedulability (whether or not all the tasks will meet their dead- 
lines) by checking their periods and CPU utilization. RMS algorithm requires that the priority of each task 
be inversely proportional to its period. The theorem restated here is: 


RMS1: A set of n independent preemptive periodic tasks scheduled by the rate monotonic 
algorithm will always meet its deadlines, for all task phasings, if: 


Fite + SUH) = n(2* ~ 1) 
UC) = 1.0. U(4) = 0.756 U7) = 0.728 
U(2) = 0.828 U(S) = 0.734 U(8) = 0.724 
U3) = 0.779 U6) = 0.734 U9) = 0.720 
U(@) = In2 = 0.69 

Where: 


= Task Computation Time 
= Task Periodicity 
, = Task Utilization 


RMS 1 is conservative, and if it doesn’t show schedulability, RMS2 can be used for a more detailed test: 


RMS2: For a set of independent, preemptive periodic tasks scheduled by RMS algorithm, 
Start all tasks at t=0. If each meets its first deadline, the deadlines will always be met. 
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Applying RMS1 to CPU 1, test case 2 after, results with: 


Task 4: C/T Ξ 1} Al < U(1)=1.0 

Task 10:C/T = .03 14 < U(2) = 0.828 
Task 11:C/T = .07 21 < U(3) =0.779 
Task 7: C/T = .10 31 < U(4) =0.756 
Task 8: C/T = .08 39 < U(S) = 0.743 
Task 5: C/T = .07 46 < U(6) =0.734 
Task 9: C/T = .04 50 < U(7) =0.728 

Task 12:C/T = .40 90 > U(8) = 0.724 Fails. 


Since RMS1 fails to show that the tasks can successfully complete their processing by their deadlines, 
RMS2 can be used to perform a check with greater detail. Note that the longest period of any task in CPU 
1 is 30, and applying RMS2 τὸ test case 2, CPU 1: 


4: Η 5 ΠΗ x δὲ " Fy & δ x 
10: [-1} a 
ll: |g 5 a 5 


5: . ie 

. 

| 2 πα —— τ ΕΝ m4 naan a 
FRB MB WY HR Bes mez = > RVSR 3D RR WR = FREE OT PT 


0 3.6 7.2 10.8 14.4 18 21.6 25.2 28.8 
tick = .36 time units 


33x 10= 3.3 
18x5 = 0.9 The first 7 tasks consume 16.48 time units of the 30 

Ψ time unit frame. This leaves 13.52 time units for the 
42x5 = 2.1 : ὴ : 
0x5 - 35 last task, which only requires 12.00. The diagram can- 
are as not show all the blocks needed due to scaling and 
56x4 = 2.24 round off errors. 
.69x4 = 2.76 
56x3 = 1.68 

16.48 


The RMS analysis performed above predicts that the set of processes will always meet their deadlines, 
and is a sample of the processing performed on the test bed during a reconfiguration calculation. Execution 
on the test bed demonstrated that the process set performed as expected in all test cases. 
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Conclusions 


One interesting conclusion was a potential problem which may occur under the described reconfigura- 
tion algorithm set when future disturbance is considered. Excluding a configuration based on its future dis- 
turbance may exclude the only possible reconfiguration which satisfies all other constraints. This results 
ina false failure. A similar circumstance may occur when pseudo resources are strictly adhered to. A change 
is needed to allow a reconfiguration to occur even though its future disturbance score is too high or pseudo 
resource limit is passed, when that is the only reconfiguration where all the CPU and memory resources 
(real) are satisfied. 


Using Rate Monotonic Scheduling to verify that the task set is schedulable and will meet all its deadlines 
has the potential to execute for longer than may be desirable. If only the conservative check is performed 
then execution time is bounded by the size of the task set. This alone is very efficient at verifying the schedul- 
ability of a set of tasks. But using only the conservative check leaves open the possibility of excluding a 
schedulable configuration. Performing the second check will prevent that possibility but at the cost of a 
potentially CPU intensive algorithm. The algorithm used in the test bed effectively identifies all the times 
when a task is started, stopped and preempted, for all tasks in a CPU for the period of the longest task in 
that CPU. The bound on its running time is O(NP) where N is the number of tasks and P is the greatest task 
period. 


Using Rate Monotonic Scheduling has another drawback in that it applies only to sets of independent 
tasks. Tasks which pass data among themselves and spend time waiting for data are not independent. On 
the other hand tasks which communicate usually have periods which facilitate the exchange of data. This 
leads to a more constrained problem than the general problem of schedulability, possibly leading to simpler 
scheduling paradigms. The test cases in this report demonstrated that the test bed performed as expected 
when the tasks were independent. 


Finally, the paradigms and algorithms used in the test bed need to be designed into a system from its be- 
ginning. Trying to convert an existing system to take advantage of them is likely to be difficult because of 
the operating environment needed. Task preemption, non-blocking system calls, control over the priority 
of tasks, and mechanisms for communicating configuration information to effected tasks all effect the archi- 
tecture and design of a system and need to be considered before the system is implemented. 
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Appendices 


A. Sample Report from the Test Bed System 


The following is an excerpt from a report generated by executing test case 2 on the test bed system. At 
about the 65 time unit mark, CPU 2 was disabled. CPU 0 picked up process 12 and all the tasks started 
executing again around time unit 100. The test ran for approximately 200 time units before the report was 
generated. 


Proc:t000**** CPU Id 0 Period: 2 Percnt:28 Loops : 80 Misses: 0 


n Start Finish Deadline Margin Missed Cstart Cstop 
0 211 267 411 144 0 211 267 
1 411 466 611 145 0 411 466 
2 611 666 811 145 0 611 666 
3 811 866 1011 145 0 811 866 
4 1011 1066 1211 145 0 1011 1066 
5 1211 1267 1411 144 0 1211 1267 
6 1411 1466 1611 145 0 1411 1466 
7 1611 166ε 1811 145 0 1611 1066 
8 1811 1866 2011 145 0 1811 1866 
9 2011 2066 2211 145 0 2011 2066 
10 2211 2266 2411 145 0 2211 2266 
11 2411 2466 2611 145 0 2411 2466 
12 2611 2666 2811 145 0 2611 2666 
13 2811 2866 3011 145 0 2811 2866 
14 3011 3066 3211 145 0 3011 3066 
15 3211 3266 3411 145 0 3211 3266 
16 3411 3466 3611 145 0 3411 3466 
17 3611 3666 3811 145 0 3611 3666 
18 3811 3866 4011 145 0 3811 3866 
19 4011 4066 4211 145 0 4011 4066 
20 4211 4266 4411 145 0 4211 4266 
21 4411 4467 4611 144 0 4411 4467 
22 4611 4666 4811 145 0 4611 4666 
23 4811 4866 5011 145 0 4811 4866 
24 5011 5066 5211 145 0 5011 5066 
25 5211 5266 5411 145 0 5211 5266 
26 5411 5467 5611 144 0 5411 5467 
27 5611 5666 5811 145 0 5611 5666 
28 5811 5866 6011 145 0 5811 5866 
29 6011 6066 6211 145 0 6011 6066 
30 6211 6266 6411 145 0 6211 6266 
31 6411 6466 6611 145 0 6411 6466 
32 10183 10238 10383 145 0 10183 10238 
33 10383 10438 10583 145 0 10383 10438 
34 10583 10638 10783 145 0 10583 10638 
35 10783 10838 10983 145 0 10783 10838 
36 10983 11038 11183 145 0 10983 11038 
37 11183 11239 11383 144 0 11183 11239 
38 11383 11438 11583 145 0 11383 11438 
39 11583 11638 11783 14§ 0 11583 11638 
40 11783 11838 11983 145 0 11783 11838 
41 11983 12038 12183 145 0 11983 12038 
42 12183 12239 12383 144 0 12183 12239 
43 12383 12438 12583 145 0 12383 12438 
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44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
78 
79 
80 


12583 
12783 
12983 
13183 
13383 
13583 
13783 
13983 
14183 
14383 
14583 
14783 
14983 
15183 
15383 
15583 
15783 
15983 
16183 
16383 
16583 
16783 
16983 
17183 
17383 
17583 
17783 
17983 
18183 
18383 
18583 
18783 
18983 
19183 
19363 
19583 

0 


12638 
12838 
13038 
13238 
13438 
13638 
13838 
14038 
14238 
14438 
14638 
14838 
15038 
15238 
15439 
15638 
15838 
16038 
16238 
16439 
16638 
16838 
17038 
17238 
17438 
17638 
17838 
18038 
18238 
18438 
18638 
18838 
19038 
19238 
19438 
19638 

0 
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12783 
12983 
13133 
13383 
13583 
13783 
13983 
14183 
14383 
14583 
14783 
14983 
15183 
15383 
15583 
15783 
15983 
16183 
16383 
16583 
16783 
16983 
17183 
17383 
17583 
17783 
17983 
18183 
18383 
18583 
18783 
18983 
19183 
19383 
19583 
19783 
19983 


Proc:t001**** CPU Id 0 
Start Finish Deadline Margin Missed Cstart Cstop 


3 


OnrAnU RP wWNFr OO 


267 

467 

667 

867 
1067 
1267 
1467 
1667 
1867 
2067 
2267 
2467 
2667 
2867 
3067 
3267 


293 

492 

692 

892 
1092 
1293 
1492 
1692 
1892 
2092 
2292 
2492 
2692 
2892 
3092 
3292 


467 

667 

867 
1067 
1267 
1467 
1667 
1867 
2067 
2267 
2467 
2667 
2867 
3067 
3267 
3467 


145 0 12583 12638 
145 0 12783 12838 
145 0 12983 13038 
145 0 13183 13238 
145 0 13383 13438 
145 0 13583 13638 
145 0 13783 13838 
145 0 13983 14038 
145 0 14183 14238 
145 0 14383 14438 
145 0 14583 14638 
145 0 14783 14838 
145 Ο 14983 15038 
145 0 15183 15238 
144 0 15383 15439 
245 0 15583 15638 
145 0 15783 15838 
145 0 15983 16038 
145 0 16183 16238 
144 0 16383 16439 
145 0 16583 16638 
145 0 16783 16838 
145 0 16983 17038 
145 0 17183 17238 
145 0 17383 17438 
145 0 17583 17638 
145 0 17783 17838 
145 0, 17983 18038 
145 0 18183 18238 
145 νυ 18383 18438 
145 0 18583 18638 
145 0 187823 18838 
145 0 18983 19038 
145 0 19183 19238 
145 0 19383 19438 
145 0 19583 19638 

0 0 0 0 

Period: 2 Perent:13 Loops : 80 

174 0 267 293 
175 0 467 492 
175 0 667 692 
175 0 867 892 
175 0 1067 1092 
174 0 1267 1293 
175 0 1467 1492 
175 0 1667 1692 
175 0 1867 1892 
175 0 2067 2092 
175 0 2267 2292 
175 0 2467 2492 
175 0 2667 2692 
175 0 2867 2892 
175 0 3067 3092 
175 0 3267 3292 

18 


Misses: 


0 
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3467 

3667 

3867 

4067 

4267 

4467 

4667 

4867 

5067 

5267 

5467 

5667 

5867 

6067 

6267 

6467 
10238 
10438 
10638 
10838 
11038 
11239 
11438 
11638 
11838 
12038 
12239 
12438 
12638 
12838 
13038 
13238 
13438 
13638 
13838 
14038 
14238 
14438 
14638 
14838 
15038 
15238 
15439 
15638 
15838 
16038 
16238 
16439 
16638 
16838 
17038 
17238 
17438 
17638 
17838 
18038 


3492 

3692 

3892 

4092 

4292 

4493 

4692 

4892 

5092 

5292 

5493 

5692 

5893 

6092 

6292 

6492 
10264 
10464 
10664 
10864 
11064 
11265 
11464 
11664 
11864 
12064 
12264 
12464 
12664 
12864 
13064 
13264 
13464 
13664 
13864 
14064 
14264 
14464 
14664 
14864 
15064 
15264 
15465 
15664 
15864 
16064 
16264 
16464 
16664 
16864 
17064 
17264 
17464 
17664 
17864 
18064 
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3667 

3867 

4067 

4267 

4467 

4667 

4867 

5067 

5267 

5467 

5667 

5867 

6067 

6267 

6467 

6667 
10438 
10638 
10838 
11038 
11238 
11438 
11638 
11838 
12038 
12238 
12438 
12638 
12838 
13038 
13238 
13438 
13638 
13838 
14038 
1423€ 
14432 
14638 
14838 
15038 
15238 
15438 
15638 
15838 
16038 
16238 
16438 
16538 
16858 
17038 
17238 
17438 
17638 
17838 
18038 
18238 


175 
175 
175 
175 
175 
174 
175 
175 
175 
175 
174 
175 
174 
175 
175 
175 
174 
174 
174 
174 
174 
173 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
173 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 
174 


19 


τὸ- οί δ ὩΣ ΝΣ ἈΝ ΣΟ τὸν ὧν τὰ ὌΔνΕ5 Ὁ ὩΣ ἘΣ ὩΣ ΘΟ ΥΣ Ὁ ἘΣ ΟΣ Σὰ ΟΥ̓ Χο Χ Ὁ ὩΣ Κα Στ αἰ πα ε ἃ ὩΣ ἘΣΘ eg 


3467 

3667 

3867 

4067 

4267 

4467 

4667 

4867 

5067 

5267 

5467 

5667 

5867 

6067 

6267 

6467 
10238 
10438 
10638 
10838 
11038 
11239 
11438 
11638 
11838 
12038 
12239 
12438 
12638 
12838 
13038 
13238 
13438 
13638 
13838 
14038 
14238 
14438 
14638 
14838 
15038 
15238 
15439 
15638 
15838 
16038 
16238 
16439 
16638 
16838 
17038 
17238 
17438 
17638 
17838 
18038 


3492 

3692 

3892 

4092 

4292 

4493 

4692 

4892 

5092 

5292 

5493 

5692 

5893 

6092 

6292 

6492 
10264 
10464 
10664 
10864 
11964 
11265 
11444 
11664 
11864 
12064 
12264 
12464 
12664 
12864 
13064 
13264 
13464 
13664 
13864 
14064 
14264 
14464 
14664 
14864 
15064 
15264 
15465 
15664 
15864 
16064 
16264 
16464 
16664 
16864 
17064 
17264 
17464 
17664 
17864 
18064 


0 


0 
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18438 
18638 
18838 
19038 
19238 
19438 
19638 
19838 
20038 


Proc:t002**** CPU Id 0 
Start Finish Deadline Margin Missed Cstart Cstop 
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OAKDMNPWNEF O 


293 
793 
1293 
1793 
2293 
2793 
3293 
3793 
4293 
4793 
5293 
5793 
6293 
10264 
10764 
11265 
11764 
12264 
12764 
13264 
13764 
14264 
14764 
15264 
15764 
16264 
16764 
17264 
17764 
18264 
18764 
19264 
0 


343 
924 
1343 
1924 
2343 
2924 
3342 
3924 
4342 
4924 
5342 
5924 
6342 
10314 
10895 
11314 
11895 
12314 
12895 
13314 
13895 
14314 
14895 
15314 
15895 
16314 
16895 
17314 
17895 
18314 
18895 
19314 
0 


793 
1293 
1793 
2293 
2793 
3293 
3793 
4293 
4793 
5293 
5793 
6293 
6793 

10764 
11264 
11764 
12264 
12764 
13264 
13764 
14264 
14764 
15264 
15764 
16264 
16764 
17264 
17764 
18264 
18764 
19264 
19764 
20264 


Proc:t003**** CPU Id 0 
Start Finish Deadline Margin Missed Cstart Cstop 


f=} 


SNOW PWNF OO 


343 
1343 
2343 
3343 
4343 
5343 
6343 

10314 


393 
1393 
2393 
3393 
4392 
5392 
6392 

10364 


1343 
2343 
3343 
4343 
5343 
6343 
7343 
11314 


174 
174 
174 
174 
174 
174 
174 
174 

0 


Period: 5 


450 
369 
450 
369 
450 
369 
451 
369 
451 
369 
451 
369 
451 
450 
369 
450 
369 
450 
369 
450 
369 
450 
369 
450 
369 
450 
369 
450 
369 


Period:10 


950 
950 
950 
950 
951 
951 
951 
950 
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0 


φῶ τὰ δ Ὁ αι χ ο Ἢ ἘΣ Σ ὃ ΟΣ co cocoa ΟΣ ὩΣ oO 


0 


0 
0 
0 
0 
0 
0 
0 


0 


Perent:10 


293 
793 
1293 
1793 
2293 
2793 
3293 
3793 
4293 
4793 
5293 
5793 
6293 
10264 
10764 
11265 
11764 
12264 
12764 
13264 
13764 
14264 
14764 
15264 
15764 
16264 
16764 
17264 
17764 
18264 
18764 
19264 
0 


Percent: 


343 
1343 
2343 
3343 
4343 
5343 
6343 

10314 


5 


0 
Loops :32 


343 
924 
1343 
1924 
2343 
2924 
3342 
3924 
4342 
4924 
5342 
5924 
6342 
10314 
10895 
11314 
11895 
12314 
12895 
13314 
13895 
14314 
14895 
15314 
15895 
16314 
16895 
17314 
17895 
18314 
18895 
19314 
0 


Loops:17 


393 
1393 
2393 
3393 
4392 
5392 
6392 

10364 


Misses: 


Misses: 


0 


0 
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8 11314 11364 12314 950 
9 12314 12364 13314 950 
10 13314 13364 14314 950 
11 14314 14364 15314 950 
12 15314 15364 16314 950 
13 16314 16364 17314 950 
14 17314 17364 18314 950 
15 18314 18364 19314 950 
16 19314 19364 20314 950 
17 0 0 21314 0 


11314 11364 
12314 12364 
13314 13364 
14314 14364 
15314 15364 
16314 16364 
17314 17364 
18314 18364 
19314 19364 

0 0 


oooooooo°c:;oc 


Proc:t012**** CPU Id 0 Period:30 Percent: 40 Loops: 3 Misses: 0 
n Start Finish Deadline Margin Missed Cstart Cstop 

10364 12968 13364 396 0 10364 12968 

13364 15969 16364 395 13364 15969 

16364 18969 19364 395 16364 18969 

19364 0 22364 0 19364 0 


WN Fe © 
ooo 


Loops indicates the number of cycles executed by the model process. 
Missed is the number of missed deadlines. 
n is the cycle index. 


Start, Finish, and Deadline are points in time. All time figures are in 100th’s of a time unit (for exam- 
ple, process t000 finished cycle 1 at 4.66 time units from the start of the test). 


Margin is the amount of time between Finish and Deadline. 
Missed is a 0/1 missed deadline indicator. 


Cstart and Cstop are time tags for the start and completion of the CPU busy loop of the model process. 
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This report was prepared under Interleaf 5.2. A template for the ANSI Z39.18 standard was created and 
used and is available upon request. 
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